Alpha State Machine #5
Conversation
|
I'm marking this as ready for review bc i'm not sure how done it needs to be. No mech-specific code in here, but the infrastructure for binding commands to states, and all the transitions are implemented. The button bindings are implemented but are just placeholders. |
spellingcat
left a comment
spellingcat
left a comment
There was a problem hiding this comment.
see the new graph i posted on #software in slack which i think simplifies things enough for the alpha
| private void addTransitions() { | ||
| bindTransition(SuperState.IDLE, SuperState.INTAKE, intakeReq); | ||
|
|
||
| bindTransition(SuperState.INTAKE, SuperState.READY, intakeReq.negate().or(isFull)); |
There was a problem hiding this comment.
add path from intake back to idle if it's empty and intake req is not true
There was a problem hiding this comment.
intake -> ready needs to be when intakereq.negate().and(is not empty)
| bindTransition( | ||
| SuperState.SCORE_FLOW, SuperState.READY, scoreReq.negate().and(isEmpty.negate())); | ||
|
|
||
| bindTransition(SuperState.SCORE_FLOW, SuperState.SCORE, scoreReq.and(continuousReq.negate())); |
There was a problem hiding this comment.
this is not that important but maybe put the bidirectional transitions next to each other
|
|
||
| isFull = new Trigger(routing::isFull); | ||
|
|
||
| isEmpty = new Trigger(routing::isEmpty); |
There was a problem hiding this comment.
i might add an isPartial or something like that for when the second beambreak is true but first is not
There was a problem hiding this comment.
I've just done !isEmpty but ig i could do this.
There was a problem hiding this comment.
!isEmpty could include full though (although i can't remember off the top of my head if that's ever relevant still)
| .and(DriverStation::isTeleop) | ||
| .or(Autos.autoFeedReq); | ||
|
|
||
| continuousReq = |
There was a problem hiding this comment.
yknow, i might actually get rid of continuous req as a separate button and just do like (intake req and score req) in place of continous req
There was a problem hiding this comment.
I felt like this gave more flexability if we want to change the bindings for continuous (like we could just make continuousReq equal to scoreReq && intakeReq, but we could also make it something else
There was a problem hiding this comment.
yeah that makes sense. cont = score + intake is good for now i think
spellingcat
left a comment
spellingcat
left a comment
There was a problem hiding this comment.
quite close. btw i'm thinking everyone should merge their subsystems into main when they're done, merge main -> this branch and make it use the actual methods, then merge this but lmk if you have another idea
| // No so sure about the end condition here. | ||
| bindTransition(SuperState.FEED_FLOW, SuperState.IDLE, flowReq.negate()); | ||
|
|
||
| // Maybe should be a transition from idle to flow as well? In case robot doesn't already have a fuel |
There was a problem hiding this comment.
i think you could probably get away with intake -> score and intake -> feed
since if flowreq = intakereq + scorereq, idle -intakereq-> intake -scorereq-> score -flowreq-> score flow, and same for feed
|
|
||
| bindCommands(SuperState.INTAKE, intake.intake(), routing.index(), shooter.rest()); | ||
|
|
||
| bindCommands(SuperState.READY, intake.rest(), routing.index(), shooter.rest()); // Maybe index at slower speed? |
There was a problem hiding this comment.
as this is kind of dependent on what irl testing tells us about power draw i think this is ok for now, we can always change it later
Co-authored-by: spellingcat <[email protected]>
Still WIP